Нормализация базы данных - этот пример нарушает 1NF? - PullRequest
Новая
       12

Нормализация базы данных - этот пример нарушает 1NF?

0 голосов
/ 21 декабря 2011

Я работаю с Access 2010. Я разрабатываю базу данных для общедоступной художественной программы - мы рисуем на стенах масштабные фрески.База данных отслеживает глухие стены города как потенциальные места для росписей.Он включает в себя информацию о самом здании и окружающей собственности, например, о участке, на котором стоит стена.

Мой главный вопрос о столе WallsMaster.Как вы можете видеть, есть около 30 полей… и еще около 10-15, которые я собираюсь добавить, в результате чего получится 45 полей, может быть, даже больше.Что касается производительности базы данных, то лучше ли разделить их на несколько таблиц или объединить их все в одну?То есть я должен разбить WallsMaster и иметь другую таблицу, которая покрывает мои общие категории в этой таблице….может быть, называется Damage, а другой - Obstruction, другой - FacesLot и т. д., а затем установить отношения FK между ними и WallsMaster?

Я думаю о правилах нормализации ... просто не уверен, что они относятся к группам связанных / повторяющихся данных в отношении 1NF.Насколько я понимаю, больше не нужно иметь таблицу с чем-то вроде AuthorName, Book1, Book2, Book3 и т. Д.

Вот примерная схема моей базы данных: 

Table: WallsMaster
WallID (PK)
StreetAddress
City
State
Zip
BldgName
Occupied_or_Vacant
Faces_Direction (NSEW)
Residential_or_Commercial
Historical_Property (Yes/No)
Visible_to_traffic (Yes/No)
Faces_Parking (Yes/No)
Faces_Fenced_Lot (Yes/No)
Faces_Abandoned_Lot (Yes/No)
Faces_Garden (Yes/No)
Faces_ParkPlayground (Yes/No)
Faces_street (Yes/No)
Wall_Surface (Lookup: Brick, Stucco, etc)
Damage_Water (Yes/No)
Damage_Crumbling (Yes/No)
Damage_Graffiti (Yes/No)
Damage_Other (Yes/No)
Obstruction_Trees (Yes/No)
Obstruction_Powerlines (Yes/No)
Obstruction_Other (Yes/No)
Number_Stories
Height
Width
Image (Link)
GoogleStreetView (Link)
Notes (memo field)

Table: WallContacts
ContactID (PK)
WallID (FK)  many:many.  i.e., one wall can have many contacts (owner, manager, tenant) and one contact can be affiliated with many properties (i.e., one owner owns several walls)
FirstName
LastName
Address
City
State
Zip
ContactType (Lookup: Owner, Manager, Neighbor, etc.)
Phone
Email

Table: WallInteraction  (Catalogs each time our staff talks to someone affiliated with that wall or conducts an inspection of the property, etc)
InteractionID(PK)
WallID (FK)
StaffName
Date
InteractionStatus
Notes
(this may expand to include more fields as we work with this more)

Спасибо!!

1 Ответ

3 голосов
/ 21 декабря 2011

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

  • Если в здании может быть несколько стен, то явыделит адрес и т. д. в отдельную таблицу зданий и свяжет ее с WallMaster в соотношении один-много (у здания может быть много стен, но стена может принадлежать только одному зданию).
  • Возможно, вы захотите рассмотретьвыделение Notes (в одном с WallsMaster), поскольку это даст вам возможность вводить несколько заметок и сохранять историю, а не перезаписывать существующие заметки.
  • Рассматривайте внешний ключ StaffID, а не StaffName на WallInteraction.
  • Также лично я переименовал бы «WallMaster» в «Wall».
...