На главную Наши проекты:
Журнал   ·   Discuz!ML   ·   Wiki   ·   DRKB   ·   Помощь проекту
ПРАВИЛА FAQ Помощь Участники Календарь Избранное RSS
msm.ru
! информация о разделе
user posted imageДанный раздел предназначается для обсуждения вопросов использования баз данных, за исключением составления запросов на SQL. Для этого выделен специальный раздел. Убедительная просьба - соблюдать "Правила форума" и не пренебрегать "Правильным оформлением своих тем". Прежде, чем создавать тему, имеет смысл заглянуть в раздел "Базы данных: FAQ", возможно там уже есть ответ.

Модераторы: Chow, Bas, MIF
Страницы: (4) [1] 2 3 ... Последняя » все  ( Перейти к последнему сообщению )  
> Выбор модели данных БД учета личного состава , Выбор модели данных БД учета личного состава
    Доброго времени суток, уважаемые форумчане!
    Я работаю Вооруженных Сил РФ. Учет личного состава ведётся на бумажных носителях. Для автоматизации учета хочу создать базу данных, удовлетворяющую следующим требованиям:
    1. У военнослужащего имеется около 90 параметров (учетных данных).
    2. Большинство из параметров (учетных данных) представляют собой сложные структуры (например, в полях «дети» необходимо содержать такую информацию как ФИО, пол, дата рождения, свидетельство о рождении и т.д.
    3. Хранение записей по нарастающей хронологии, т.е. хранить сведения обо всех детях, датах и номерах приказов о присвоении званий, назначении должностей, периодах службы и т.д.
    4. Возможность вывода любых форм (отчетов) в различных комбинациях параметров (учетных данных) и подсчёт всевозможной статистики.
    5. Вывод форм (отчетов) в документы MS Word и Excel.
    6. БД несетевая, но мобильная: быстрый перенос (копирование) БД через флеш-носители на компьютеры, несвязанные между собой сетью.

    Вопросы:
    1. Какую модель данных (технологию, парадигму программирования) выбрать? Реляционную, объектно-ориентированную или что-то иное?
    2. Возможно ли реализовать требуемую БД в MS Access или 1С?
    3. Какую литературу посоветуете по реализации моей БД?

    Заранее спасибо. Прошу прощения, если ошибся в терминах. БД изучал в университете 5 лет назад.
      Цитата flintpit @
      Реляционную, объектно-ориентированную или что-то иное?

      Реляционную + объектно-ориентированную.

      Цитата flintpit @
      2. Возможно ли реализовать требуемую БД в MS Access или 1С?

      Можно, но как быть с
      Цитата flintpit @
      но мобильная: быстрый перенос (копирование) БД через флеш-носители на компьютеры

      Одно из требований это установленный офис и 1С.


      Цитата flintpit @
      2. Большинство из параметров (учетных данных) представляют собой сложные структуры (например, в полях «дети» необходимо содержать такую информацию как ФИО, пол, дата рождения, свидетельство о рождении и т.д.

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

      Добавлено
      Так и с остальными структурами, типа место жительства, образования и тд и тп
      Сообщение отредактировано: Bas -
        Поставленная задача на самом деле требует не столько внимания к организации хранения данных (все озвученные данные можно хранить хоть в plain text или там XML, это несильно скажется на производительности с учётом прогнозируемых объёмов данных), сколько к интерфейсной части (создание необходимых обработок и генерации выходных форм, в т.ч. экспортируемых).

        С учётом этого настоятельно рекомендую забыть про одноэску. MS Access в принципе неплох - но возникнут озвученные выше проблемы с необходимостью наличия установленного офиса, причём именно в Проф версии, ибо в стандарте Акса тупо нет, плюс определённые сложности в связи с отсутствием штатных средств резервирования и наличием ограничений на размер БД (с учётом того, что файл БД одновременно используется и как файл-кэш для материализации промежуточных данных).

        Однако я бы предложил посмотреть в сторону альтернативных инструментов, которые специально затачиваются именно под создание связки БД+интерфейс, но при этом сами портабельны (только интерфейсный обработчик либо комплекс с БД) и содержат более вменяемый встроенный сервер БД. Например, типа MyVisualDatabase (она бесплатна для некоммерческого использования).
        Сообщение отредактировано: Akina -
          Сперва небольшое отступление. Последние 2 с половиной года разрабатывал АРМ центра социального обслуживания населения. Как оказалось впоследствии, именно грамотное построение структур учета - основной головняк разработки. Не последующие регистрации работ/консультаций/обслуживаний, а именно регистрация и учет граждан... И мне есть чего сказать :lol:

          Цитата flintpit @
          Вопросы:
          1. Какую модель данных (технологию, парадигму программирования) выбрать? Реляционную, объектно-ориентированную или что-то иное?

          Строго реляционную. Потому, как с помощью этого решаемо на 100%, потому как более широко используемо, потому как больше кому будет помочь советом.

          Цитата flintpit @

          2. Возможно ли реализовать требуемую БД в MS Access или 1С?

          Возможно. Но с этими двумя на практике не знаком, без комментариев.
          Цитата flintpit @
          3. Какую литературу посоветуете по реализации моей БД?

          Сперва искать ликбез по проектированию реляционных БД.

          Ну а теперь "вкусненькое" ...

          Типа броне-костюм для строевой подготовки на минном поле :lol:

          1) "Реляцоинность" данных! Без этого в будущем будут невзгоды и лишения, которые, согласно присяге, вам нужно будет преодолевать. А оно надо вам?

          Простой пример. Общеупотребимая практика. Для учета граждан создается основная таблица, состоящая из множества полей типа VARCHAR - ФИО, Адрес проживания, иногда и телефон ... Но, и фамилии меняются, и адреса, и телефоны. Со временем. А вам нужно что?

          Вместо этого собираем наши информационные сущности как из "конструктора".

          а) Создаем каталог "Описателей", типа:
          ExpandedWrap disabled
            ID - уникальный идентификатор
            Name - название (используемое в UI), например ФАМИЛИЯ
            Prompt - короткая подсказка
            Help - длинный хелп по назначению и способу заполнения
            Type - тип данных (INT,FLOAT,VARCHAR) либо ссылки на рубрики, на сущности, ... тут нужна фантазия

          б) Создаем каталог "Информационных сущностей", типа:
          ExpandedWrap disabled
            ID - уникальный идентификатор
            Name - название сущности (используемое в UI), например "КАРТОЧКА ВОЕННОСЛУЖАЩЕГО"

          c) Создаем каталог "Конструкторов Информационных сущностей", типа:
          ExpandedWrap disabled
            ID - уникальный идентификатор
            Target - ссылка на б)
            Info - ссылка на a)
            Cost - желаемый порядок размещения в UI


          Что в результате? В результате вместо статической структуры, известной на момент сборки - получаем возможность строить нужные нам динамические структуры на момент ввода в эксплуатацию, равно как и во время самой эксплуатации. Нужно нам 90 полей - пожалуйста, нужно 91-е поле, нет проблем - решается администрированием путем создания (при необходимости поля) и "привязки" его к нужной информационной сущности.

          2) "Версионность" данных! Вот оно самое:

          Цитата flintpit @
          Хранение записей по нарастающей хронологии

          Как в "Карточке военнослужащего" правильно изменить описатель "Образование"? Правильно, нужно создать таблицу "Актуализация", типа:
          ExpandedWrap disabled
            Id - уникальный идентификатор
            Date - дата изменения
            Type - тип изменения
            Rel - ссылка на новое значение
            Cause - ссылка на рубрикатор причин
            Note - коментарии

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

          3) "Журналирование" данных!

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

          Ну естественно, не нужно путать принцип "Бритвы Оккама" с неоправданным упрощением информационных моделей.

          По поводу "движка БД" - посоветую глянуть в сторону SQLite. Сам с ней не работал, но в планах - намереваюсь.

          Удачи!

          Добавлено
          Вдогоночку. Забыл упомянуть про "Отчетность". Давно надумалось неплохое решение - если хранить отчеты, их UI-входные формы и выходные формы, в самой БД. Нет проблем не только для M$ Access! Простой пример. Сам интерфейс пишется на Qt/C++ , а отчеты хранятся в БД в виде VARCHAR, содержащие скриптовые подпрограммы на QtScript. Переработка отчетности совсем не потребует переработки программы. Более того, идеально решается вопрос дистрибуции изменений в отчетности.
            Цитата JoeUser @
            Забыл упомянуть про "Отчетность".

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

            Добавлено
            Цитата JoeUser @
            Сперва искать ликбез по проектированию реляционных БД.

            поиск по форуму
              Как удалить неправильно написанное сообщение?

              Добавлено
              Как удалить неправильное написанное сообщение?

              Добавлено
              Цитата JoeUser @
              Вместо этого собираем наши информационные сущности как из "конструктора".

              а) Создаем каталог "Описателей", типа:
              ExpandedWrap disabled
                ID - уникальный идентификатор
                Name - название (используемое в UI), например ФАМИЛИЯ
                Prompt - короткая подсказка
                Help - длинный хелп по назначению и способу заполнения
                Type - тип данных (INT,FLOAT,VARCHAR) либо ссылки на рубрики, на сущности, ... тут нужна фантазия

              б) Создаем каталог "Информационных сущностей", типа:
              ExpandedWrap disabled
                ID - уникальный идентификатор
                Name - название сущности (используемое в UI), например "КАРТОЧКА ВОЕННОСЛУЖАЩЕГО"

              c) Создаем каталог "Конструкторов Информационных сущностей", типа:
              ExpandedWrap disabled
                ID - уникальный идентификатор
                Target - ссылка на б)
                Info - ссылка на a)
                Cost - желаемый порядок размещения в UI


              2) "Версионность" данных! Вот оно самое:

              Цитата flintpit @
              Хранение записей по нарастающей хронологии

              Как в "Карточке военнослужащего" правильно изменить описатель "Образование"? Правильно, нужно создать таблицу "Актуализация", типа:
              ExpandedWrap disabled
                Id - уникальный идентификатор
                Date - дата изменения
                Type - тип изменения
                Rel - ссылка на новое значение
                Cause - ссылка на рубрикатор причин
                Note - коментарии

              Спасибо за столь развернутый ответ. Обязательно использую. Но откуда эти строки кода? Какой язык? Изучал С++, РНР, SQL, но эти не знакомы :(
              Сообщение отредактировано: flintpit -
                Это не "язык". Это описание структур в принципе. А на чём его реализовать - дело десятое.
                  Проанализировав множество советов на различных форумах, пришел к решению строить простейшую базу в МS Access. В качестве теории выбрал Хомоненко «Базы данных» (2004), по которой учили в универе, знакомый текст лучше вспоминается, да и сама книга написана на основе зарубежной литературы. В помощь для разъяснения сложных вопросов взял Дейта «Введение в системы баз данных» (2005), которого все рекомендуют, и Крёнке «Теория и практика построения баз данных» (2003) из вызывающей доверие серии «Классика computer science» издательства Питер.
                  В качестве практического руководства по MS Access взял Сеннова и Гурвица.
                  Всем спасибо за ответы!
                    Цитата flintpit @
                    пришел к решению строить простейшую базу в МS Access
                    Зря... Акцесс хорош для домашней библиотеки. Но никак не подходит для твоего случая.
                    ЗЫ - в его SQL-коде даже комментарии нельзя вводить!!!
                    Рекомендую зарегистрироваться на Oracle, скачать то, что тебе нужно (а не обломки с пиратских торрентов) и пользоваться возможностями полноценного СУБД-движка (лицензия для твоих целей ИМХО вообще не нужна).
                    ---
                    ЗЗЫ - а в части обмена - Oracle DataPump в помощь. Не так быстро, как замена одного ACCDB на другой, но и не так критично по времени. У тебя не СУБД реального времени (не телефонная компания)!
                    Сообщение отредактировано: #SI# -
                      Цитата #SI# @
                      Рекомендую зарегистрироваться на Oracle, скачать то, что тебе нужно (а не обломки с пиратских торрентов) и пользоваться возможностями полноценного СУБД-движка (лицензия для твоих целей ИМХО вообще не нужна).

                      А теперь расскажи, как с твоим советом предлагается воплощать исходное требование
                      Цитата flintpit @
                      БД несетевая, но мобильная: быстрый перенос (копирование) БД через флеш-носители на компьютеры, несвязанные между собой сетью.

                      Причём не в части переноса данных (DataPump с этим действительно справится), а в части переноса сервера БД, без которого нихренашеньки не станет работать. Не припоминаю я существования у них встраиваемого сервера что-то... да и для невстраиваемого аппаратная конфигурация должна быть, скажем прямо, нетривиальная, что в реалиях ВС РФ наличествует далеко не везде...
                        Akina, не думаю, что речь идёт о БД командира отделения. А вот на уровне части (военкомата етс...) - твой вопрос несущественен.
                        ЗЫ - хотелось бы знать, что реально написано в ТЗ на разработку.
                          #SI#
                          Я думаю, что это личная (возможно, и общественная, но никак не официальная) инициатива низовых работников. Которые задолбались работать в бумаге. Более того - почти убеждён, что это так. И, следовательно, ни о каком ТЗ речи не идёт. Зато идёт речь о максимально простых и доступных, в т.ч. по освоению и углублённому изучению, средствах разработки - причём строго локальных, а не визуально-облачных. И в этом смысле Access как бы не в тройке (ну или во всяком случае в группе) лидеров.
                            Как "карманный" вариант, думаю, потянет такое решение: Using MySQL on a Raspberry Pi. Конечно на старте будет непросто, нужно будет много чего осваивать параллельно, кроме SQL и проектирования реляционных БД. Но, по идее, может получится конфетка. Этакая биг-флэшка с дисплеем :)
                              Цитата Akina @
                              <...ППКС...>причём строго локальных, а не визуально-облачных. И в этом смысле Access
                              есть почти у всех нахаляву. В составе пиратского офиса :D . С этим - согласен.
                              Но для ЭТОЙ конкретной задачи Акцесс НЕ ГОДИТСЯ! ИМХО!

                              Добавлено
                              Цитата JoeUser @
                              Этакая биг-флэшка с дисплеем
                              Идеальный вариант. Но, похоже, ТС этим будет заниматься в свободное от основной работы время... :(
                                Цитата #SI# @
                                для ЭТОЙ конкретной задачи Акцесс НЕ ГОДИТСЯ! ИМХО!

                                Категорически не согласен.
                                На моей памяти (лет эдак 15 назад было) эксперт-криминалист самостоятельно, практически в одиночку, создал на Аксессе вполне работоспособную БД для фиксации, накопления и анализа результатов экспертиз. В начале работы он с трудом использовал Эксель. Через 2 года у него приложение было полностью работоспособно. Среднее количество атрибутов на первичную сущность - штук 30-40, количество типов первичных сущностей - порядка 20, количество выходных форм - с полсотни, автоматизированных обработок штук 5...
                                Глаза боятся, а руки - делают. И даже если в конце концов ТС придёт к выводу, что Access как инструмент для его задачи не очень удачен, он успеет накопить достаточные знания и опыт, чтобы реализовать следующую версию на более "продвинутых" средствах.
                                0 пользователей читают эту тему (0 гостей и 0 скрытых пользователей)
                                0 пользователей:


                                Рейтинг@Mail.ru
                                [ Script execution time: 0,0496 ]   [ 16 queries used ]   [ Generated: 19.03.24, 07:28 GMT ]