Unit 10 Blog
This week was pretty nostalgic for me since I constructed a relational database more than twenty years ago. The application I used called ADBM, is still around, with its most recent release 7.4 featuring capabilities for 250 tables per database with 4000 fields per table, those interested can learn more at http://www.maconsys.com/ . Of course the system I constructed is nowhere near that complex. I did get familiar with adding users and setting permissions as I constructed my RDBMS. The GUI features of the 7 series are far more user friendly than the DOS version I used to construct my relational database. I still use the DOS version every day on our LAN as does my staff. The readings and exercises in this unit really made me understand why ADBM has all those very strange rules and constraints that forced me to create fields and properties and links that would work together to do what I wanted the system to do, more or less anyway. For example, The Not Null constraint in MySQL is equivalent to the Required Field in ADBM.
After just a few days of reading and hands on I have a much deeper understanding of what is going on under the hood of my relational database system. Pretty sure that what I did more than 20 years ago, and still use today, would not be held in high esteem by most DBA personnel but hey it has allowed me to retrieve , search and sort data in ways that would otherwise be impossible.
I'm still trying to get my head around the join routines, inner, outer and full so perhaps after reading the activity postings this week some of this will be clearer. When I constructed my ADBM RDBMS I did learn about primary keys that had to be unique and dynamic value tables that allowed me to create brief codes for products that made data entry consistent and fast. I've been told by a succession of our IT guys that my DOS RDBMS is a poor excuse for a DB but I've challenged them to come up with a replacement for twenty years using MS Access or anything else. To date the sound of crickets is an apt metaphor for their response.
As I learn more about DBA I'll be revisiting my ADBM RDBMS and will try to use the lessons learned in DigIn to improve the functionality of the system. Hey, who says you can't teach an old dog new tricks...
Sunday, July 25, 2010
Monday, July 19, 2010
Unit 9 DB
Unit 9 Blog Databases
I found the concept of cardinality difficult and I'm not sure that I understand it well enough to create a simple ERD. However, it seems from a scan of the literature as represented in this week's readings that cardinality relates to the minimum and maximum instances of an Entity that can be associated with another Entity. For example one invoice can list many items but each invoice can have only one customer. A customer may have many invoices but only one customer billing address.
Entity relationships seem to break down when there is a many to many relationship. The example we encountered in the readings involved a Student Entity and a Class Entity. There are many students and each student may be taking more than one class. Each Class Entity has many students. So with that a many to many relationship develops. This condition or relationship will cause problems for the database. Apparently the solution is to construct a bridge table entitled Student/Class with a concatenated primary key joining the Student PK and the Class PK.
I found the same problem when developing my Artists, Works, Museums database. The simple solution would have been to say each artist may create or or more works of art and each work can have one and only one artist. Thus preserving a one to many relationship between the Artist and Works tables. But with collaboration such a large part of the the digital world this is really not now if it ever was a useful or sustainable perspective.
Since one artist may create many works and each work may be the result of one or more artists the problematic many to many relationship arises. To solve this problem, I inserted a bridge table between the Artist Table and the Work Table entitled Artist/Work Table with the primary key being a concatenation of the Artist ID and the Work ID. In this bridge table , I added columns for the the Artist ID and Work ID so that both became non-key attributes. This restored a one to many relationship between the Artist Table and the Artist/Work Table as one artist may have many works in which she collaborated, but that part of the collaboration by a particular artist relates back to that one artist. Also each work may be the collaborative result of one or more artists but that particular instance of collaboration relates to one and only one work. A one to many relationship also exists between the Artist/Work Table and the Work Table.
At least I think...
I found the concept of cardinality difficult and I'm not sure that I understand it well enough to create a simple ERD. However, it seems from a scan of the literature as represented in this week's readings that cardinality relates to the minimum and maximum instances of an Entity that can be associated with another Entity. For example one invoice can list many items but each invoice can have only one customer. A customer may have many invoices but only one customer billing address.
Entity relationships seem to break down when there is a many to many relationship. The example we encountered in the readings involved a Student Entity and a Class Entity. There are many students and each student may be taking more than one class. Each Class Entity has many students. So with that a many to many relationship develops. This condition or relationship will cause problems for the database. Apparently the solution is to construct a bridge table entitled Student/Class with a concatenated primary key joining the Student PK and the Class PK.
I found the same problem when developing my Artists, Works, Museums database. The simple solution would have been to say each artist may create or or more works of art and each work can have one and only one artist. Thus preserving a one to many relationship between the Artist and Works tables. But with collaboration such a large part of the the digital world this is really not now if it ever was a useful or sustainable perspective.
Since one artist may create many works and each work may be the result of one or more artists the problematic many to many relationship arises. To solve this problem, I inserted a bridge table between the Artist Table and the Work Table entitled Artist/Work Table with the primary key being a concatenation of the Artist ID and the Work ID. In this bridge table , I added columns for the the Artist ID and Work ID so that both became non-key attributes. This restored a one to many relationship between the Artist Table and the Artist/Work Table as one artist may have many works in which she collaborated, but that part of the collaboration by a particular artist relates back to that one artist. Also each work may be the collaborative result of one or more artists but that particular instance of collaboration relates to one and only one work. A one to many relationship also exists between the Artist/Work Table and the Work Table.
At least I think...
Sunday, July 11, 2010
Unit 8 Technology Plans
I found the Gerding and MacKellar reading “Applying for Technology Grants” to be an especially informative survey of technology resources. I had no idea for example that there were hundreds of community based technology centers funded by the US Dept of Education established to bridge the national digital divide. Also the Gerding and MacKellar article points out some of the best studies and reports on how technology and the internet has and will impact American life. These web sites are sources that I plan to access on a regular schedule going forward, in fact I have added each site to my Google RSS reader.
Another reading I found very helpful was the Dugan reading “Information Technology Plans.” Dugan reminds his readers of a theme that permeates all of the readings this week, that technology plans must advance and support the institution's mission and goals. This gets into the whole vision and strategic directions discussion with many questioning whether technology hasn't often been an end in itself rather than a tool in service to a larger end. Technology is so complex and multifacted that it is easy to fall into the trap of becoming enmeshed in the details of technology deployment while failing to evaluate how well the technology is furthering the larger cause of the organization. At a college this might be as simple as asking the question: “has the acquisition and application of technologies improved learning?”
Planning would seem to be at the core of ensuring that technology is not an end in itself but rather a means to an end. Hence the need for the technology plan. Like the larger strategic plan the technology plan involves lots of stakeholders and participants but one should be careful not to let the process drag on for so long that the plan becomes obsolete. After all a strategic plan and especially a technology plan is a document that charts a course of action over the next 12 to 36 months. It is not a long range plan which is really another type of management document. Aligning the planning process timeline with the fiscal budget cycle is a good pratical recommendation by Dugan.
One of the authors this week observed that libraries formerly constructed stacks designed to be serviceable for 50 years or more. Today technology cycles range from 18 to 36 months. There really is no precedent for this kind of environment. Our planning is often overwhelmed by the pace of change.
To meet this challenge , metrics should be constructed to measure progress and outcomes. Is the tech plan on time and within budget? How well does the plan advance the mission of the organization? The last measurement being subjective and difficult to quantify. The Balanced Scorecard metric is one structured approach to this sort of management problem that has proven helpful. This metic measures success from four perspectives including 1) user perspective, 2) internal processes (workflow efficiency), 3) the finance perspective, 4) how well does the technology plan as realized help us to met new challenges? It is also important to understand that the plan will need to be recalibrated and revised at annual intervals to keep the implementation of the technology plan on schedule, on course and aligned with the mission of the organization.
I have been involved in a host of technology initiatives over the course of my career. These include, in roughly chronological order, training personnel in the use of Lexis and Westlaw first generation hardware - dedicated terminals; writing annual tech budget requests; installing and utilizing PCs for legal research and library and office administrative tasks; designing and configuring a relational database system to monitor library expenditures, acquisitions, and equipment inventory control; managing the installation and implementation of the library's LAN; migrating the relational database system to a LAN configuration; introduction of web access to the court and public, serving on the hiring committee for the court's first dedicated LAN administrator; managing the installation, operation and maintenance of a WAN CD Tower; serving as a trainer on the first statewide judicial laptop distribution project, training personel in the efficient use of web based legal research resources; supervising the creation and maintenance of the law library's web site; hiring and supervising the library's pc analyst; implementing an internal virtual reference service to judges and court attorneys; participating as a node in a statewide 800 general information line; supervising the implementation of the library's first generation ILS; supervising the implementation of the library's second generation ILS; training library staff to operate both generations of the library's ILS.
Dedicated professional network technologists were not available in the courts until the mid 1990's and even today few if any are available to support library operations. So for the most part initiatives are still local or develop from a community of similarly situation law libraries in other counties.
All of the technology projects listed above involved extensive planning and documentation on my part. These included annual budget proposals sufficient to articulate the needs, constituencies, costs, outcomes and evaluation methodolgy for the technology requested. I would have benefited from having researched the literature of technology planning more systematically as I have done this week. Resources like TechSoup and WebJunction would have been a great help but weren't available back then. The literature I read this week had not yet been published when I began my involvement in technology planning, procurement and implemenation going back as far as the mid 1980's.
I will end this week's blog right now, not wanting to further exhaust the reader.
Another reading I found very helpful was the Dugan reading “Information Technology Plans.” Dugan reminds his readers of a theme that permeates all of the readings this week, that technology plans must advance and support the institution's mission and goals. This gets into the whole vision and strategic directions discussion with many questioning whether technology hasn't often been an end in itself rather than a tool in service to a larger end. Technology is so complex and multifacted that it is easy to fall into the trap of becoming enmeshed in the details of technology deployment while failing to evaluate how well the technology is furthering the larger cause of the organization. At a college this might be as simple as asking the question: “has the acquisition and application of technologies improved learning?”
Planning would seem to be at the core of ensuring that technology is not an end in itself but rather a means to an end. Hence the need for the technology plan. Like the larger strategic plan the technology plan involves lots of stakeholders and participants but one should be careful not to let the process drag on for so long that the plan becomes obsolete. After all a strategic plan and especially a technology plan is a document that charts a course of action over the next 12 to 36 months. It is not a long range plan which is really another type of management document. Aligning the planning process timeline with the fiscal budget cycle is a good pratical recommendation by Dugan.
One of the authors this week observed that libraries formerly constructed stacks designed to be serviceable for 50 years or more. Today technology cycles range from 18 to 36 months. There really is no precedent for this kind of environment. Our planning is often overwhelmed by the pace of change.
To meet this challenge , metrics should be constructed to measure progress and outcomes. Is the tech plan on time and within budget? How well does the plan advance the mission of the organization? The last measurement being subjective and difficult to quantify. The Balanced Scorecard metric is one structured approach to this sort of management problem that has proven helpful. This metic measures success from four perspectives including 1) user perspective, 2) internal processes (workflow efficiency), 3) the finance perspective, 4) how well does the technology plan as realized help us to met new challenges? It is also important to understand that the plan will need to be recalibrated and revised at annual intervals to keep the implementation of the technology plan on schedule, on course and aligned with the mission of the organization.
I have been involved in a host of technology initiatives over the course of my career. These include, in roughly chronological order, training personnel in the use of Lexis and Westlaw first generation hardware - dedicated terminals; writing annual tech budget requests; installing and utilizing PCs for legal research and library and office administrative tasks; designing and configuring a relational database system to monitor library expenditures, acquisitions, and equipment inventory control; managing the installation and implementation of the library's LAN; migrating the relational database system to a LAN configuration; introduction of web access to the court and public, serving on the hiring committee for the court's first dedicated LAN administrator; managing the installation, operation and maintenance of a WAN CD Tower; serving as a trainer on the first statewide judicial laptop distribution project, training personel in the efficient use of web based legal research resources; supervising the creation and maintenance of the law library's web site; hiring and supervising the library's pc analyst; implementing an internal virtual reference service to judges and court attorneys; participating as a node in a statewide 800 general information line; supervising the implementation of the library's first generation ILS; supervising the implementation of the library's second generation ILS; training library staff to operate both generations of the library's ILS.
Dedicated professional network technologists were not available in the courts until the mid 1990's and even today few if any are available to support library operations. So for the most part initiatives are still local or develop from a community of similarly situation law libraries in other counties.
All of the technology projects listed above involved extensive planning and documentation on my part. These included annual budget proposals sufficient to articulate the needs, constituencies, costs, outcomes and evaluation methodolgy for the technology requested. I would have benefited from having researched the literature of technology planning more systematically as I have done this week. Resources like TechSoup and WebJunction would have been a great help but weren't available back then. The literature I read this week had not yet been published when I began my involvement in technology planning, procurement and implemenation going back as far as the mid 1980's.
I will end this week's blog right now, not wanting to further exhaust the reader.
Friday, July 2, 2010
Unit 7 XML
Unit 7 Blog
I found the UACBT “Introduction to XML” by Mark Long to be very helpful for learning about XML. Over the last few years I've seen many references to XML but never really understood just what it is or how it relates to HTML. Another term that I've come across a lot in the professional literature is XHTML - same problem - a lot of folks writing about it but until this week I didn't understand that XHTML is really HTML with a structure and rules that makes it more interoperable with XML. While HTML is fat and lazy and is helped out by the “understanding” browser, XHTML is highly structured and won't display properly in a browser unless it is well formed. At least I think that is the concept behind XHTML. Also XML is a way of tagging your data so that it can be reused for a variety of purposes. Generally HTML is good at presentation and style but isn't very good at describing the data embedded in the HTML document.
Anyway returning to XML the UACBT videos are really helpful, and Mark Long is excellent at breaking down the concepts of XML in a way that allows a newbie like myself to understand some of the basics. On the other hand I found the YouTube video “Just Enough XML to Survive” to be way over my head. The pace was too fast; I kept stopping and restarting and the part about XML Schemas was way more than I could digest in this my first week's exposure to XML. I'll try reading more about XML and going through more of the UACBT videos on DTD and XML Schemas before going back to the YouTube video. Perhaps by then it will make more sense.
As to my Ubuntu practice system, everything is operational and going well. I followed all of the directions in the Unit 7 Assignments and all went according to plan. The PuTTY application gave me access to a command line console that I needed in the absence of a monitor. Using my host machine to send commands to the practice system was very cool. Didn't shove my practice system behind the sofa though, since my Ethernet cable isn't that long and I know it needs to be connected to the router. My study is now a hopeless jumble of ups, cables, cable modem, router, desktop, etc. , and likely to remain so until 672 and 675 are completed.
I found the UACBT “Introduction to XML” by Mark Long to be very helpful for learning about XML. Over the last few years I've seen many references to XML but never really understood just what it is or how it relates to HTML. Another term that I've come across a lot in the professional literature is XHTML - same problem - a lot of folks writing about it but until this week I didn't understand that XHTML is really HTML with a structure and rules that makes it more interoperable with XML. While HTML is fat and lazy and is helped out by the “understanding” browser, XHTML is highly structured and won't display properly in a browser unless it is well formed. At least I think that is the concept behind XHTML. Also XML is a way of tagging your data so that it can be reused for a variety of purposes. Generally HTML is good at presentation and style but isn't very good at describing the data embedded in the HTML document.
Anyway returning to XML the UACBT videos are really helpful, and Mark Long is excellent at breaking down the concepts of XML in a way that allows a newbie like myself to understand some of the basics. On the other hand I found the YouTube video “Just Enough XML to Survive” to be way over my head. The pace was too fast; I kept stopping and restarting and the part about XML Schemas was way more than I could digest in this my first week's exposure to XML. I'll try reading more about XML and going through more of the UACBT videos on DTD and XML Schemas before going back to the YouTube video. Perhaps by then it will make more sense.
As to my Ubuntu practice system, everything is operational and going well. I followed all of the directions in the Unit 7 Assignments and all went according to plan. The PuTTY application gave me access to a command line console that I needed in the absence of a monitor. Using my host machine to send commands to the practice system was very cool. Didn't shove my practice system behind the sofa though, since my Ethernet cable isn't that long and I know it needs to be connected to the router. My study is now a hopeless jumble of ups, cables, cable modem, router, desktop, etc. , and likely to remain so until 672 and 675 are completed.
Subscribe to:
Posts (Atom)