Системы управления базами данных access 2003

Какие типы СУБД в соответствии с моделями данных вы знаете?

Этот вопрос по SQL предполагает не просто назвать, но и дать краткое описание каждому типу.

Существует несколько типов СУБД:

1. Реляционные, которые поддерживают установку связей между таблицами с помощью первичных и внешних ключей. Пример — MySQL.
2. Flat File — базы данных с двумерными файлами, в которых содержатся записи одного типа и отсутствует связь с другими файлами, как в реляционных. Пример — Excel.
3. Иерархические подразумевают наличие записей, связанных друг с другом по принципу отношений один-к-одному или один-ко-многим. А вот для отношений многие-ко-многим следует использовать реляционную модель. Пример — Adabas.
4. Сетевые похожи на иерархические, но в этом случае «ребёнок» может иметь несколько «родителей» и наоборот. Примеры — IDS и IDMS.
5. Объектно-ориентированные СУБД работают с базами данных, которые состоят из объектов, используемых в ООП. Объекты группируются в классы и называются экземплярами, а классы в свою очередь взаимодействуют через методы. Пример — Versant.
6. Объектно-реляционные обладают преимуществами реляционной и объектно-ориентированной моделей. Пример — IBM Db2.
7. Многомерная модель является разновидностью реляционной и использует многомерные структуры. Часто представляется в виде кубов данных. Пример — Oracle Essbase.
8. Гибридные состоят из двух и более типов баз данных. Используются в том случае, если одного типа недостаточно для обработки всех запросов. Пример — Altibase HDВ.

3

Суррогатные ключи

В некоторых случаях естественный ключ, который однозначно идентифицирует кортеж в отношении, может быть неудобным для использования при разработке программного обеспечения. Например, он может включать несколько столбцов или большие текстовые поля. В таких случаях вместо первичного ключа можно использовать суррогатный ключ. В других ситуациях может быть более одного ключа-кандидата для отношения, и очевидно, что никакой ключ-кандидат не является предпочтительным. Суррогатный ключ может использоваться в качестве первичного ключа, чтобы избежать искусственного примата одного ключа-кандидата над другими.

Поскольку первичные ключи существуют в первую очередь для удобства программиста, суррогатные первичные ключи часто используются, во многих случаях исключительно, при разработке приложений баз данных.

Из-за популярности суррогатных первичных ключей многие разработчики и в некоторых случаях даже теоретики стали рассматривать суррогатные первичные ключи как неотъемлемую часть реляционной модели данных. Во многом это связано с переносом принципов из модели объектно-ориентированного программирования в модель реляционной, создавая гибридную объектно-реляционную модель. В ORM, подобном шаблону активной записи , эти дополнительные ограничения накладываются на первичные ключи:

• Первичные ключи должны быть неизменными, то есть никогда не изменяться и не использоваться повторно; их следует удалить вместе со связанной записью.
• Первичные ключи должны быть анонимными целыми или числовыми идентификаторами.

Однако ни одно из этих ограничений не является частью реляционной модели или какого-либо стандарта SQL. Следует проявлять должную осмотрительность при принятии решения о неизменности значений первичных ключей во время проектирования базы данных и приложения. Некоторые системы баз данных даже подразумевают, что значения в столбцах первичного ключа нельзя изменить с помощью оператора SQL.

Создать первичный ключ (оператор ALTER TABLE)

Если ваша таблица уже существует и вы хотите добавить к ней позже первичный ключ, вы можете использовать оператор ALTER TABLE для создания первичного ключа.

Синтаксис

Синтаксис для создания первичного ключа с помощью оператора ALTER TABLE в SQL.

ALTER TABLE table_name ADD CONSTRAINT constraint_name PRIMARY KEY (column1, column2, … column_n);

table_name

Имя таблицы для изменения. Это таблица, к которой вы хотите добавить первичный ключ

constraint_name

Название первичного ключа

column1, column2, … column_n

Столбцы, составляющие первичный ключ

Пример

Давайте посмотрим, как создать первичный ключ с помощью оператора ALTER TABLE в SQL. Скажем так, у нас уже есть таблица suppliers, созданная в нашей базе данных. Мы могли бы добавить первичный ключ к таблице suppliers с помощью следующего оператора ALTER TABLE.

PgSQL

ALTER TABLE suppliers
ADD CONSTRAINT suppliers_pk
PRIMARY KEY (supplier_id);

1 2 3

ALTERTABLEsuppliers ADDCONSTRAINTsuppliers_pk PRIMARYKEY(supplier_id);

В этом примере мы создали первичный ключ для существующей таблицы suppliers, который называется sources_pk. Он состоит из столбца supplier_id. Мы также могли бы создать первичный ключ с более чем одним полем, как показано ниже.

PgSQL

ALTER TABLE suppliers
ADD CONSTRAINT suppliers_pk
PRIMARY KEY (supplier_id, supplier_name);

1 2 3

ALTERTABLEsuppliers ADDCONSTRAINTsuppliers_pk PRIMARYKEY(supplier_id,supplier_name);

Этот пример создал бы первичный ключ с именем supplier_pk, который состоит из комбинации столбцов supplier_id и supplier_name.

Что такое внешний ключ

Внешний ключ используется для ссылки на другую таблицу. Он также называется ссылочным ключом. Это столбец или комбинация столбцов, которые соответствуют первичному ключу в другой таблице. Другими словами, внешний ключ в таблице является первичным ключом некоторой другой таблицы.

Рисунок 1: Первичный и Внешний ключ

Например, предположим, что есть база данных продаж. Имеются таблицы клиентов и продуктов. Таблица customer содержит столбцы customer_id, name, address и contact_no. Первичный ключ таблицы клиента — customer_id. Товар имеет столбцы product_id, name, quality. Первичный ключ таблицы продукта — product_id. Размещение product_id в таблице клиентов создаст связь между двумя таблицами. Product_id в таблице product является первичным ключом, но это внешний ключ в customer_table. Аналогично, можно соединять таблицы в базе данных, используя внешний ключ.

Резюме

• Агрегат — это коллекция данных, с которой мы взаимодействуем как с отдель­ной единицей. Агрегаты образуют границы для операций ACID, применяемых в базе данных.
• Базы данных типа “ключ-значение”, документные базы данных и семейства столбцов представляют собой агрегатно-ориентированные базы данных.
• Агрегаты упрощают управление хранением данных на кластерах.
• Агрегатно-ориентированные базы данных лучше всего работают, когда боль­шинство операций над данными выполняются в одном и том же агрегате; безагрегатные базы данных лучше работают, когда операции выполняются над дан­ными, которые относятся к многочисленным разным формациям.

Вас заинтересует / Intresting for you:

Как правильно выбрать базу дан… 4181 просмотров Administrator Sun, 07 Oct 2018, 08:31:24

Альтернативные модели данных и… 4102 просмотров Дэйзи ак-Макарова Sun, 09 Sep 2018, 10:39:19

Модели данных и языки запросов 551 просмотров Дэн Wed, 06 Mar 2019, 16:11:35

Основные модели данных: иерарх… 5934 просмотров Дэйзи ак-Макарова Sun, 09 Sep 2018, 10:28:33

Author: Денис

Другие статьи автора:

Создание таблиц

Последнее обновление: 26.06.2017

Ключевым объектом в базе данных являются таблицы. Таблицы состоят из строк и столбцов. Столбцы определяют тип информации, которая хранится, а строки содержат
значения для этих столбцов.

В прошлой теме была создана база данных university. Теперь определим в ней первую таблицу. Опять же для создания таблицы в SQL Server Management Studio
можно применить скрипт на языке SQL, либо воспользоваться графическим дизайнером. В данном случае выберем второе.

Для этого раскроем узел базы данных university в SQL Server Management Studio, нажмем на его подузел Tables
правой кнопкой мыши и далее в контексто меню выберем New -> Table…:

После этого нам откроется дизайнер таблицы. В центральной части в таблице необходимо ввести данные о столбцах таблицы. Дизайнер содержит три поля:

• Column Name: имя столбца

• Data Type: тип данных столбца. Тип данных определяет, какие данные могут храниться
  в этом столбце. Например, если столбец представляет числовой тип, то он может хранить только числа.

• Allow Nulls: может ли отсутствовать значение у столбца, то есть может ли он быть пустым

Допустим, нам надо создать таблицу с данными учащихся в учебном заведении. Для этого в дизайнере таблицы четыре столбца: Id, FirstName, LastName и Year, которые будут представлять
соответственно уникальный идентификатор пользователя, его имя, фамилию и год рождения. У первого и четвертого столбца надо указать тип int (то есть целочисленный), а у столбцов FirstName и LastName — тип nvarchar(50)
(строковый).

Затем в окне Properties, которая содержит свойства таблицы, в поле Name надо ввести имя таблицы — Students, а в
поле Identity ввести Id, то есть тем самым указывая, что столбец Id будет идентификатором.

Имя таблицы должно быть уникальным в рамках базы данных. Как правило, название таблицы отражает название сущности, которая в ней хранится. Например,
мы хотим сохранить студентов, поэтому таблица называется Students (слово студент во множественном числе на английском языке). Существуют
разные мнения по поводу того, стоит использовать название сущности в единственном или множественном числе (Student или Students). В данном случае вопрос наименования таблицы всецело ложится на разработчика базы данных.

И в конце нам надо отметить, что столбец Id будет выполнять роль первичного ключа (primary key).
Первичный ключ уникально идентифицирует каждую строку. В роли первичного ключа может выступать один столбец, а может и несколько.

Для установки первичного ключа нажмем на столбец Id правой кнопкой мыши и в появившемся меню выберем пункт Set Primary Key.

После этого напротив поля Id должен появиться золотой ключик. Этот ключик будет указывать, что столбец Id будет выполнять роль
первичного ключа.

И после сохранения в базе данных university появится таблица Students:

Мы можем заметить, что название таблицы на самом деле начинается с префикса dbo. Этот префикс представляет схему.
Схема определяет контейнер, который хранит объекты. То есть схема логически разграничивает базы данных. Если схема явным образом не указывается при создании объекта, то объект принадлежит
схеме по умолчанию — схеме dbo.

Нажмем правой кнопкой мыши на название таблицы, и нам отобразится контекстное меню с опциями:

С помощью этих опций можно управлять таблицей. Так, опция Delete позволяет удалить таблицу. Опция Design откроет окно дизайнера таблицы,
где мы можем при необходимости внести изменения в ее структуру.

Для добавления начальных данных можно выбрать опцию Edit Top 200 Rows. Она открывает в виде таблицы 200 первых строк и
позволяет их изменить. Но так как у нас таблица только создана, то естественно в ней будет никаких данных. Введем пару строк — пару студентов, указав
необходимые данные для столбцов:

В данном случае я добавил две строки.

Затем опять же по клику на таблицу правой кнопкой мыши мы можем выбрать в контекстном меню пункт Select To 1000 Rows,
и будет запущен скрипт, который отобразит первые 1000 строк из таблицы:

НазадВперед

Как узнать, сколько памяти на видеокарте?

Видеокарта является неотъемлемой частью любого компьютера и без нее было бы невозможно передать изображение на монитор. В современных компьютерах используется как встроенная видеокарта (она интегрирована в материнскую плату), так и в виде дополнительного модуля.

Для работы на ПК вполне достаточно встроенного видеоадаптера, а вот для работы в графических приложениях и для игр обычно используют дискретную видеокарту.

Если вам понадобилось выяснить объем устройства, сделать это будет совсем нетрудно. Я покажу вам несколько способов, на которые вы затратите не более пары минут своего времени.

Смотрим свойства системы

Традиционно начинаю обзор с простейшего метода, доступного каждому пользователю. Пример показан на основе Windows 7.

Первым делом заходим на рабочий стол, нажимаем на правую кнопку мыши, после чего появляется меню. В нем выбираем пункт «Разрешение экрана».

Перед вами открылось окно, где вы можете увидеть установленное разрешение экрана. В этом же окне вы можете увидеть пункт «Дополнительные параметры». Нажмите на него.

Кстати, не забывайте о том, что полный объем памяти можно выяснить только в том случае, если для видеокарты установлены драйвера. Если они отсутствуют, система будет показывать объем в 32 Мб.

CPU-Z

Если вдруг указанный выше способ вам не помог или вы просто не смогли им воспользоваться, обратимся за помощью к сторонним программам. Таких достаточно много, включая Everest, AIDA64. CPU-Z и т.д. Что лучше использовать, решать только вам. Я покажу пример на CPU-Z.

Скачиваем программу с официального сайта и устанавливаем. После установки запускаем наше приложение и открываем вкладку Graphics. Видим пункт Memory и подпункт Size — здесь находится объем памяти вашей видеокарты.

Другие способы

Существуют и другие способы узнать объем видеокарты. Например, воспользоваться средством диагностики DirectX. Я хотел было описать этот способ, только система почему-то показываем мне совсем не тот объем видеокарты, каким он является. С чем это связано — загадка.

https://youtube.com/watch?v=k9IPlMVYH0Q

Еще вариант — это посмотреть название видеоадаптера на коробке, а затем вбить наименование в поисковик. Но и тут есть загвоздка: под одним и тем же названием может выпускаться несколько одинаковых видеокарт, но с разным объем памяти.

Таким образом я считаю, что двух описанных выше способов будет предостаточно.

Внешние ключи

• Если сущности А и В связывает сущность С, то она должна содержать внешние ключи, которые соответствуют первичным ключам сущностей А и В.
• Если сущность В характеризует сущность А, то она должна содержать внешний ключ, который соответствует первичному ключу сущности А.

Для каждого из внешних ключей нужно получить ответы на 3 вопроса:

1-й вопрос: может ли значение данного внешнего ключа быть неопределенным (NULL-значением)?

Например, при поставках такая ситуация невозможна – поставка неизвестного продукта или поставка, которая осуществляется неизвестным поставщиком, не имеет смысла. Но может существовать блюдо с неизвестным видом (горячее, суп и т.д.).

2-й вопрос: что должно произойти при УДАЛЕНИИ экземпляра сущности с первичным ключом, на который ссылается внешний ключ?

Например, если удаляется поставщик, осуществивший хотя бы одну поставку, существует 3 варианта, при которых поставка:

• КАСКАДИРУЕТСЯ – удаляются все поставки данного поставщика.
• ОГРАНИЧИВАЕТСЯ – удаляются только не осуществлявшие поставок поставщики. В противном случае удаление отклоняется.
• УСТАНАВЛИВАЕТСЯ – для всех поставок данного поставщика значение внешнего ключа устанавливается в NULL (неопределенное), а после данный поставщик удаляется. Подобная возможность, естественно, не может быть применена, если внешний ключ не может содержать неопределенных значений (NULL).

3-й вопрос – какая операция должна выполняться при ОБНОВЛЕНИИ первичного ключа сущности, на который ссылается внешний ключ?

Например, при попытке обновления номера поставщика, который выполнил хотя бы одну поставку возможны те же 3 варианта, что и при удалении:

• КАСКАДИРУЕТСЯ – обновляется также и внешний ключ в поставках данного поставщика.
• ОГРАНИЧИВАЕТСЯ – обновляются первичные ключи только не осуществлявших поставок поставщиков, в противном случае операция обновления отклоняется.
• УСТАНАВЛИВАЕТСЯ – для всех поставок поставщика, который обновляется, внешний ключ устанавливается в NULL-значение, а после выполняется обновление первичного ключа поставщика. Подобная возможность, естественно, не может быть применена, если внешний ключ не может содержать неопределенных значений (NULL).

Следовательно, каждый внешний ключ в проекте должен специфицироваться не только полем или комбинацией полей, которые составляют данный внешний ключ и сущностью, которую идентифицирует этот ключ, но также и ответами на вопросы (3 ограничения, относящиеся к данному внешнему ключу).

Простой и составной первичный ключ

Primary key может быть простым и составным. Если уникальность записи определяется значением только в одном поле, как описано выше, мы имеем дело с простым ключом. Составной ключ – это первичный ключ базы данных, состоящий из двух и более полей. Рассмотрим следующее отношение клиентов банка.

Ф. И. О.	Дата рождения	Серия паспорта	Номер паспорта
Иванов П.А.	12.05.1996	75	0553009
Сергеев В.Т.	14.07.1958	71	4100654
Краснов Л.В.	22.01.2001	73	1265165

Паспорта людей могут содержать одни и те же серии либо номера, но паспортов с одним и тем же сочетанием серии и номера не существует. Таким образом, поля «Серия паспорта» и «Номер паспорта» станут составным ключом указанного отношения, однозначно идентифицируя человека.

Определение первичных ключей в SQL

Первичные ключи определены в помощью ограничения PRIMARY KEY. Синтаксис для добавления такого ограничения к существующей таблице определен в SQL: 2003 следующим образом:

ALTER TABLE <table identifier> 
    ADD  CONSTRAINT <constraint identifier>  
    PRIMARY KEY ( <column name>  {, <column name> }...  )

Первичный ключ также можно указать непосредственно при создании таблицы. В стандарте SQL первичные ключи могут состоять из одного или нескольких столбцов. Каждый столбец, участвующий в первичном ключе, неявно определяется как NOT NULL

Обратите внимание, что некоторые СУБД требуют явной пометки столбцов первичного ключа как .

CREATE TABLE table_name (
   
   ...
)

Если первичный ключ состоит только из одного столбца, столбец можно пометить как таковой, используя следующий синтаксис:

CREATE TABLE table_name (
   id_col  INT  PRIMARY KEY,
   col2    CHARACTER VARYING(20),
   ...
)

6.2. Первичные ключи и индексирование

Access
относится к реляционным
базам данных, информация в которых
хранится в связанных
таблицах. Каждая таблица должна иметь
уникальное имя. Для организации связи
между таблицами каждая таблица должна
содержать одно или несколько полей,
однозначно определяющих каждую запись
в таблице. Такие поля называют первичным
ключом
таблицы. Если для таблицы определен
первичный ключ, то Microsoft Access предотвращает
дублирование ключа или ввод нулевых
значений в эти поля.

В
Access допускается определение первичных
ключей трех типов:

Ключевые
поля счетчика.
Поле счетчика можно задать таким образом,
чтобы при добавлении каждой новой записи
в таблицу в это поле автоматически
вносился порядковый номер. Указание
такого поля в качестве ключевого является
наиболее простым способом создания
первичного ключа. Если до сохранения
созданной таблицы ключевые поля не были
определены, Access предлагает создать
ключевое поле автоматически. При нажатии
кнопки «Да» будет создано ключевое
поле счетчика.

Простой
ключ.
Если поле содержит уникальные значения,
такие как коды товара или инвентарные
номера, то это поле можно определить
как первичный ключ. В качестве ключа
можно определить любое поле, содержащее
данные, если это поле не содержит
повторяющихся или нулевых значений.

Составной
ключ.
В случаях, когда невозможно гарантировать
уникальность значений каждого поля,
существует возможность создать ключ,
состоящий из нескольких полей. Для
составного ключа существенным может
оказаться порядок образующих ключ
полей. Сортировка записей осуществляется
в соответствии с порядком ключевых
полей, отображаемых в бланке режима
конструктора таблицы.

Рис.
6.2. Пример таблицы, требующей создания
составного ключа

Для
создания составного ключа следует в
режиме конструктора выделить нужные
поля, удерживая клавишу CTRL,
а затем выполнить команду ПРАВКА/КЛЮЧЕВОЕ
ПОЛЕ (кнопка
).

Если
порядок полей в составном первичном
ключе должен отличаться от порядка
полей в таблице, следует выполнить
команду ВИД/ИНДЕКСЫ (кнопка
на панели инструментов), чтобы открытьокно
«Индексы». В этом окне и следует
указать другой порядок полей дляиндексас именем «PrimaryKey» (см. рис.6.3).

Рис.
6.3. Окно для изменения порядка полей в
составном ключе

Связь
между таблицами осуществляется через
совпадающие значения одного или
нескольких ключевых полей. Ключи
хранятся в индексированном
(упорядоченном) виде, что обеспечивает
быстрый доступ к записям таблицы
во время поиска.

Если
приходится часто искать записи по
полю, не являющемуся ключевым, ускорить
поиск можно, проиндексировав таблицу
по соответствующим полям. Индексирование

позволяет поддерживать записи
упорядоченными по выбранному полю.
Индекс можно создать по одному
(простой индекс)
или нескольким полям (составной
индекс).
Для создания простого индекса
используется свойство поля
“Индексированное поле”, оно может
содержать и не уникальные значения,
например, повторяющиеся фамилии.
Возможны три типа индексации: Нет, Да
(Допускаются совпадения), Да (Совпадения
не допускаются). При индексировании
по умолчанию задаётся порядок
сортировки
по возрастанию.

Пример
окна для создания индексированного
поля типа «Да (Совпадения не допускаются)»
приведён на рис. 6.4 – это поле «КОД
ТОВАРА» таблицы «ТОВАРЫ».

Рис.
6.4. Вид таблицы «ТОВАРЫ» в режиме
конструктора

Такой
тип индексации описывает уникальное
поле, т.е. товары могут иметь повторяющиеся
значения в полях «КАТЕГОРИЯ»,
«НАИМЕНОВАНИЕ» и даже «ЦЕНА»,
но поле «КОД ТОВАРА» однозначно
идентифицирует этот товар.

1.2.5. Первичный ключ

Мы уже достаточно много говорили про ключевые поля, но ни разу их не использовали. Самое интересное, что все работало. Это преимущество, а может недостаток базы данных Microsoft SQL Server и MS Access. В таблицах Paradox такой трюк не пройдет и без наличия ключевого поля таблица будет доступна только для чтения.

В какой-то степени ключи являются ограничениями, и их можно было рассматривать вместе с оператором CHECK, потому что объявление происходит схожим образом и даже используется оператор CONSTRAINT. Давайте посмотрим на этот процесс на примере. Для этого создадим таблицу из двух полей «guid» и «vcName». При этом поле «guid» устанавливается как первичный ключ:

CREATE TABLE Globally_Unique_Data
(
 guid uniqueidentifier DEFAULT NEWID(),
 vcName varchar(50),
 CONSTRAINT PK_guid PRIMARY KEY (Guid)
)

Самое вкусное здесь это строка CONSTRAINT. Как мы знаем, после этого ключевого слова идет название ограничения, и объявления ключа не является исключением. Для именования первичного ключа, я рекомендую использовать именование типа PK_имя, где имя – это имя поля, которое должно стать главным ключом. Сокращение PK происходит от Primary Key (первичный ключ).

После этого, вместо ключевого слова CHECK, которое мы использовали в ограничениях, стоит оператор PRIMARY KEY, Именно это указывает на то, что нам необходима не проверка, а первичный ключ. В скобках указывается одно, или несколько полей, которые будут составлять ключ.

Помните, что в ключевом поле не может быть одинакового значения у двух строк, в этом ограничение первичного ключа идентично ограничению уникальности. Это значит, что если сделать поле для хранения фамилии первичным ключом, то в такую таблицу нельзя будет записать двух Ивановых с разными именами. Это нарушает ограничение первичного ключа. Именно поэтому ключи являются ограничениями и объявляются также как и ограничение CHECK. Но это не верно только для первичных ключей и вторичных с уникальностью.

В данном примере, в качестве первичного ключа выступает поле типа uniqueidentifier (GUID). Значение по умолчанию для этого поля – результат выполнения серверной процедуры NEWID.

Внимание

Только один первичный ключ может быть создан для таблицы

Для простоты примеров, в качестве ключа желательно использовать численный тип и если позволяет база данных, то будет лучше, если он будет типа «autoincrement» (автоматически увеличивающееся/уменьшающееся число). В MS SQL Server таким полем является IDENTITY, а в MS Access это поле типа «счетчик».

Следующий пример показывает, как создать таблицу товаров, в которой в качестве первичного ключа выступает целочисленное поле с автоматическим увеличением:

CREATE TABLE Товары
(
  id int IDENTITY(1, 1),
  товар varchar(50),
  Цена money,
  Количество numeric(10, 2),
  CONSTRAINT PK_id PRIMARY KEY (id)
)

Именно такой тип ключа мы будем использовать чаще всего, потому что в ключевом поле будут храниться легкие для восприятия числа и с ними проще и нагляднее работать.

Первичный ключ может состоять из более, чем одной колонки. Следующий пример создает таблицу, в которой поля «id» и «Товар» образуют первичный ключ, а значит, будет создан индекс уникальности на оба поля:

CREATE TABLE Товары1
(
  id int IDENTITY(1, 1),
  Товар varchar(50),
  Цена money,
  Количество numeric(10, 2),
  CONSTRAINT PK_id PRIMARY KEY 
         (id, )
)

Очень часто программисты создают базу данных с ключевым полем в виде целого числа, но при этом в задаче четко стоит, что определенные поля должны быть уникальными. А почему не создать сразу первичный ключ из тех полей, которые должны быть уникальны и не надо будет создавать отдельные решения для данной проблемы.

Единственный недостаток первичного ключа из нескольких колонок – проблемы создания связей. Тут приходиться выкручиваться различными методами, но проблема все же решаема. Достаточно только ввести поле типа uniqueidentifier и производить связь по нему. Да, в этом случае у нас получаются уникальными первичный ключ и поле типа uniqueidentifier, но эта избыточность в результате не будет больше, чем та же таблица, где первичный ключ uniqueidentifier, а на поля, которые должны быть уникальными установлено ограничение уникальности. Что выбрать? Зависит от конкретной задачи и от того, с чем вам удобнее работать.

Ключи и ссылочная целостность в MySQL и Oracle

Oracle поддерживает первичные, уникальные, внешние ключи в полном объеме. Oracle поддерживает следующие правила ссылочной целостности:

• NO ACTION (устанавливается по умолчанию) в более жестком, чем по стандарту SQL 92, варианте: запрещается изменение и удаление строк родительской таблицы, для которых имеются связанные строки в дочерних таблицах.
• ON DELETE CASCADE.

Более сложные правила ссылочной целостности в Oracle можно реализовать через механизм триггеров.

MySQL версии 4.1 (последняя на момент написания статьи стабильная версия) позволяет в командах CREATE / ALTER TABLE задавать фразы REFERENCES / FOREIGN KEY, но в работе никак их не учитывает и реально внешние ключи не создает. Соответственно правила ссылочной целостности, реализуемые через внешние ключи, в MySQL не поддерживаются. И все заботы по обеспечению целостности и непротиворечивости информации в базе MySQL ложатся на плечи разработчиков клиентских приложений.

Требования второй нормальной формы (2NF)

Чтобы база данных находилась во второй нормальной форме (2NF), необходимо чтобы ее таблицы удовлетворяли следующим требованиям:

• Таблица должна находиться в первой нормальной форме
• Таблица должна иметь ключ
• Все неключевые столбцы таблицы должны зависеть от полного ключа (в случае если он составной)

Если ключ составной, т.е. состоит из нескольких столбцов, то все остальные неключевые столбцы должны зависеть от всего ключа, т.е. от всех столбцов в этом ключе. Если какой-то атрибут (столбец) зависит только от одного столбца в ключе, значит, база данных не находится во второй нормальной форме.

Иными словами, в таблице не должно быть данных, которые можно получить, зная только половину ключа, т.е. только один столбец из составного ключа.

Главное правило второй нормальной формы (2NF) звучит следующим образом

Руководство по проектированию реляционных баз данных (10-13 часть из 15) [перевод]

Перевод

Продолжение.
Предыдущие части: 1-3, 4-6, 7-9

10. Нормализация баз данных

Указания для правильного проектирования реляционных баз данных изложены в реляционной модели данных. Они собраны в 5 групп, которые называются нормальными формами. Первая нормальная форма представляет самый низкий уровень нормализации баз данных. Пятый уровень представляет высший уровень нормализации.
Нормальные формы – это рекомендации по проектированию баз данных. Вы не обязаны придерживаться всех пяти нормальных форм при проектировании баз данных. Тем не менее, рекомендуется нормализовать базу данных в некоторой степени потому, что этот процесс имеет ряд существенных преимуществ с точки зрения эффективности и удобства обращения с вашей базой данных.