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

Тема в разделе "Базы данных", создана пользователем SimonSmith, 19 ноя 2008.

Статус темы:
Закрыта.
Модераторы: latteo
  1. SimonSmith

    SimonSmith Постоялец

    Регистр.:
    25 сен 2008
    Сообщения:
    147
    Симпатии:
    32
    нормализация бд, функциональная зависимость

    кто-нить делал нормализацию базы на sql server 2000? помогите, нужен код с помошью которого делатся нормализация..., используя нормальные формы 1,2...:nezn: X->Y
     
  2. Liver

    Liver

    Регистр.:
    24 сен 2008
    Сообщения:
    316
    Симпатии:
    91
    А причем тут sql server? Нормализация - процесс творческий, независимый от бд. К тому же нормализованные таблицы не всегда хороши при большой нагрузке и приходится использовать разные ухищрения. Поэтому такое может выполнить только человек
     
  3. SimonSmith

    SimonSmith Постоялец

    Регистр.:
    25 сен 2008
    Сообщения:
    147
    Симпатии:
    32
    да, но не надо все автоматом между 2мя таблицами кодом....:nezn:
    просто есть работка на сйл сервере вот и дали задание (
     
  4. Liver

    Liver

    Регистр.:
    24 сен 2008
    Сообщения:
    316
    Симпатии:
    91
    А что мешает сделать один раз ручками? процесс ведь интуитивно простой.
     
  5. SimonSmith

    SimonSmith Постоялец

    Регистр.:
    25 сен 2008
    Сообщения:
    147
    Симпатии:
    32
    вот иммено если б я знал как то б не создал тему :nezn:



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

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


    DECLARE @x_contr varchar(5),
    @x_data datetime
    DECLARE @y_contr varchar(5),
    @y_data datetime
    SELECT @x_contr = contr, @x_data = data
    FROM comenzi

    DECLARE cursor_com CURSOR FOR
    SELECT contr, data FROM Comenzi
    where contr='003'
    order by contr desc
    OPEN cursor_com

    FETCH cursor_com INTO @x_contr, @x_data
    FETCH cursor_com INTO @y_contr, @y_data
    /*if @x_contr=@y_contr
    begin
    if @x_data=@y_data
    select 'exista'
    end
    else
    ROLLBACK
    select 'nu exista'
    */
    /*if @x_contr=@y_contr and @x_data=@y_data
    begin
    select 'exista'
    end
    else
    if @x_contr=@y_contr and @x_data!=@y_data
    begin
    select 'nu exista'
    end
    */

    /*while (@x_contr=@y_contr)
    BEGIN

    if (@x_data=@y_data)
    begin
    PRINT('exista')
    --PRINT (@x_contr + ' ' +@y_contr +' ' +)
    break

    end

    if (@x_data!=@y_data)
    begin
    PRINT('nu exista')
    BREAK
    end

    END
    */





    CLOSE cursor_com
    DEALLOCATE cursor_com



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

    indian.rider Постоялец

    Регистр.:
    20 окт 2008
    Сообщения:
    119
    Симпатии:
    26
    По моему, Вы что-то не то делаете.

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

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

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

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

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

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

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

    Или о чем речь?
     
  7. SimonSmith

    SimonSmith Постоялец

    Регистр.:
    25 сен 2008
    Сообщения:
    147
    Симпатии:
    32
    indian.rider

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

    теперь мне тоже самое надо и сделать....
    [​IMG]

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

    indian.rider Постоялец

    Регистр.:
    20 окт 2008
    Сообщения:
    119
    Симпатии:
    26

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

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

    И если предположить, что у Вас существуют отдельно таблица клиентов и таблица сотрудников, то в колонке номер клиента должен быть id клиента, реальный номер (типа внешний ключ). С сотрудниками аналогично.
     
  9. keyoff

    keyoff Постоялец

    Регистр.:
    29 янв 2007
    Сообщения:
    122
    Симпатии:
    41
    номер комнаты и номер сотрудника просится в отдельную сущность :) (что-то типа "расписание работы сотрудников") конечно нужно разобраться что является чьим атрибутом или комната для сотрудника или сотрудник для комнаты тудой же можно слить и время :)

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

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

    zerdek

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

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