нормализация бд

Статус
В этой теме нельзя размещать новые ответы.

SimonSmith

Мастер
Регистрация
25 Сен 2008
Сообщения
148
Реакции
34
нормализация бд, функциональная зависимость

кто-нить делал нормализацию базы на sql server 2000? помогите, нужен код с помошью которого делатся нормализация..., используя нормальные формы 1,2...:nezn: X->Y
 
А причем тут sql server? Нормализация - процесс творческий, независимый от бд. К тому же нормализованные таблицы не всегда хороши при большой нагрузке и приходится использовать разные ухищрения. Поэтому такое может выполнить только человек
 
да, но не надо все автоматом между 2мя таблицами кодом....:nezn:
просто есть работка на сйл сервере вот и дали задание (
 
А что мешает сделать один раз ручками? процесс ведь интуитивно простой.
 
А что мешает сделать один раз ручками? процесс ведь интуитивно простой.

вот иммено если б я знал как то б не создал тему :nezn:



блин, я немного перепутал...ээээ...мне надо сделать функциональную зависимость между 2мя колонками в таблице

нуу тут немного помозговал и получилось вот такое:



тут 3 метода проверки 1ого столбика со 2ым и если существует функциональная зависимость то ПРИНТ сообщение, если нет, то тоже...
а есть ли другой способ проверить данную фичу? :)
 
По моему, Вы что-то не то делаете.

В моем понимании Нормализация выглядит так:

1. рисуешь карандашом квадратики (таблички) на бумаге. можно конечно использовать для отрисовки и автоматические средства: Sybase PowerDesigner...

2. читаешь о 3-х нормальных ;) формах БД. Есть и другие, но этого достаточно.

3. карандашом на бумаге "нормализуешь" БД.

А на практике чаще приходится приводить БД в "ненормальное" состояние. Чтобы она быстрее работала к примеру.

И нарисовав пару-тройку структур БД уже не задумываешься о нормализации. А делаешь именно то, что тебе нужно. И красиво получается :)

Добавлено через 3 минуты
блин, я немного перепутал...ээээ...мне надо сделать функциональную зависимость между 2мя колонками в таблице

Зависимость между колонками одной таблицы? Такого не бывает.

Или о чем речь?
 
indian.rider

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

теперь мне тоже самое надо и сделать....


проверяем зависимость между "Номер клиента" - > "дата собеседования"
если же C345 повторявшийся 2 раза содержит повторение 13.10.03 тож 2 раза то функциональная зависимость существует.
 
indian.rider

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

теперь мне тоже самое надо и сделать....
*** скрытое содержание ***

проверяем зависимость между "Номер клиента" - > "дата собеседования"
если же C345 повторявшийся 2 раза содержит повторение 13.10.03 тож 2 раза то функциональная зависимость существует.


Нет. Это вовсе не зависимость.

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

И если предположить, что у Вас существуют отдельно таблица клиентов и таблица сотрудников, то в колонке номер клиента должен быть id клиента, реальный номер (типа внешний ключ). С сотрудниками аналогично.
 
indian.rider
проверяем зависимость между "Номер клиента" - > "дата собеседования"
если же C345 повторявшийся 2 раза содержит повторение 13.10.03 тож 2 раза то функциональная зависимость существует.

номер комнаты и номер сотрудника просится в отдельную сущность :) (что-то типа "расписание работы сотрудников") конечно нужно разобраться что является чьим атрибутом или комната для сотрудника или сотрудник для комнаты тудой же можно слить и время :)

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

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

[skip]

проверяем зависимость между "Номер клиента" - > "дата собеседования"
если же C345 повторявшийся 2 раза содержит повторение 13.10.03 тож 2 раза то функциональная зависимость существует.

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

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