Дизайн базы данных и нормализация - PullRequest
Новая
       25

Дизайн базы данных и нормализация

0 голосов
/ 29 марта 2011

Я занимаюсь разработкой подобного AddressBook проекта в VB.NET.Разрабатывая базу данных в SQL Server2005, я хочу следовать принципам нормализации и поддерживать степень ее нормализации на максимально высоком уровне.

Я использую следующие поля: 

Create table AddressBook_Contact
(
Contact_ID int Primary Key,FirstName varchar(15),MiddleName varchar(15),LastName varchar(15),BirthDay datetime,HomeCountry varchar(20),HomeState varchar(20),HomeCity varchar(20),HomeMobile varchar(40),HomePhone varchar(40),HomeMobile varchar(40),HomeFax varchar(40),HomeZipCode varchar(10),HomeEmail varchar(50),HomeAddress text, 
BusIndustry varchar(20),BusCompany varchar(20),BusWebsite varchar (30),BusCountry varchar(20),BusState varchar(20),BusCity varchar(20),BusMobile varchar(40),BusPhone varchar(40),BusFax varchar(40),BusZipCode varchar(10),BusEmail varchar(50),
BusAddress text,Note text
)

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

Если я создаю отдельные таблицы для контактов (Biodata, HomeInfo, BusinessInfo) 

create table AddressBook_Bio
(
BookID int Primary Key,
Title varchar(15),
FirstName varchar(15),
SecondName varchar(15),
LastName varchar(15),
BirthDay datetime,
Note text
)

create table AddressBook_Home
(
'My question in this case is should i declare BookID as foreign key or primary key to the table and why?'
FOREIGN KEY (BookID) REFERENCES AddressBook_ContactBio(BookID),
HCountry varchar(20),
HState varchar(20),
HCity varchar(20),
HMobile varchar(40),
HPhone varchar(40),
HFax varchar(40),
HZipCode varchar(10),
HEmail varchar(50),
HAddress text
)

create table AddressBook_Business
(
same issue as "AddressBook_Home"
)

Спасибо за заботу, чтобы выразить и поделиться своим мнением, знаниями.

Ответы [ 3 ]

0 голосов
/ 29 марта 2011

Если будет только один домашний адрес и один служебный адрес, то первая структура на самом деле не «против нормализации» - она ​​выражает структуру данных.

Если вы хотите разрешить несколько адресов (1, 2 или более, или даже ноль), вам следует создать отдельную таблицу адресов (возможно, с колонкой «тип», в которой указано, является ли это домашний, служебный или другой адрес).

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

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

Тот факт, что вам интересно, должен ли BookID быть первичным ключом в таблице * _Address, демонстрирует, что вы разбиваете что-то на две таблицы, когда на самом деле это должна быть одна.

0 голосов
/ 29 марта 2011

Высшая нормальная форма, которая всегда достижима, - 6NF .Проще говоря, таблица в 6NF будет иметь ключ (который может содержать несколько столбцов) плюс не более одного дополнительного атрибута (обратите внимание, что атрибут может иметь субатомные элементы, каждый из которых имеет свой собственный столбец, например, адрес имеет субатомные элементы zipcode, state, country,так далее).Поэтому, по крайней мере, у вас должны быть отдельные таблицы для Note, HMobile, HPHone, HFax, HEmail и Note, возможно, BirthDate, если он не является частью ключа (я бы предположил, что это так).

0 голосов
/ 29 марта 2011

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

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

...